1. Technical Field
This application is related to the field of management and establishment of a security mechanisms and key material in issued personal security devices in a field environment.
2. Description of Related Art
Personal Security Devices (PSDs), for example, smart cards, may use a multi-step process where information and programs necessary to use the PSD are loaded therein by a manufacturer prior to distribution. The information may include an initial security mechanism (SM) that may be used to access the PSD and/or may allow the PSD to be used for secure transactions. The information may also include applications that facilitate the SM provided by the PSD (e.g., a program to facilitate door access may include a specific door access security mechanism). FIG. 1 illustrates a system 30 that uses a card loader 32 and a control device 34 to initialize a PSD 36. The control device 34 (e.g., a programmed computer workstation) contains the initial SM and contains application(s) which are provided to the loader 32 which writes the information to the PSD 36. As shown in FIG. 2, after being initialized, the PSD 36 contains a set of initial applications 42 and an initial SM 44. Of course, other mechanisms (not shown) exist for a manufacturer to initialize the PSD 36.
A manufactured and pre-loaded PSD may be sent to an end user which may then use equipment, such as door access equipment, that reads the PSD and authenticates a holder using an application security mechanism (SM), such as a copy of the secret key or perhaps another, related, key (e.g., a public key corresponding to a private key stored on the PSD). A drawback to such a system is that one purchaser may receive PSDs having the same or similar SMs as PSDs purchased by another, unrelated, purchaser. Thus, it may be possible for a malicious user to use the SM information in the PDSs and/or in the PSD readers to gain unauthorized access to another user's system. Some purchasers guard against this by customizing factory-supplied PSDs with their own SMs after purchase. However, unlike the controlled environment of a manufacturing facility, a user site may not present a sufficient opportunity to reprogram every card received from a manufacturer, especially since, in many cases, partial programming/modification of a personal security device could leave the device in an inconsistent state.
In addition, physical access control systems, while updating applications in the field, do so item by item since, in many cases, an underlying card mechanism does not allow for better updating. If a change needs to be atomic, the reader performing the update may implement some transactional logic to recover from a premature PSD removal without making the PSD unusable, which may require additional memory space on the PSD and possibly complex business logic in the reader. Alternatively, the reader may not implement application level transactional logic and thus, in some situations, the PSD may become unusable if the PSD is prematurely removed while performing an application update.
Note that while the DESFire system (all versions) provides transaction support, the scope of the transactions only span the application data objects, but not system objects or properties such as access keys or application related system data, or the existence of the application. Thus, even with DESFire, it is not possible to use one atomic transaction to securely deploy a new application in the field or even update the state of a PSD involving more than one system object.
Accordingly, it is desirable to provide a system where custom security mechanism(s) and corresponding application(s) may be atomically loaded onto PSDs in an efficient manner.